Field of the Invention
The present invention relates to message processing in a message hub and more particularly to high-speed high volume message processing.
Description of the Related Art
A message hub is middleware disposed within a programmatic infrastructure that supports the exchange of messages between distributed computing systems. In this regard, the message brokering operability of a message hub allows application modules to be distributed over heterogeneous platforms while communicating through message queues managed by a messaging component and reduces the complexity of developing applications that span multiple operating systems and network protocols. As such, the message hub creates a distributed communications layer that insulates the application developer from the details of the various operating system and network interfaces.
Unlike messaging appliances that merely consolidate existing messaging services onto a convenient hardware form factor, the most recent generation of messaging hubs are specifically engineered to deliver massive scale communications beyond the enterprise. These messaging appliances deliver publish and subscribe messaging for machine-to-machine communications, communicatively connecting to a multitude of devices and sensors present with the universe of the Internet. These messaging appliances therefore dramatically scale the number of concurrently connected devices, enabling large volumes of events to be streamed into analytics engines for processing big data.
Of note, most applications utilizing messaging hubs to exchange data, whether between client and server, between processing nodes, processing stages, or threads of execution, require each of low latency—namely one to one hundred microseconds—high throughput—one hundred thousand to ten million messages per second) and also high concurrency—namely multiple persisted messages in flight at once. However the latency costs, when using normal queues in a messaging hub, are in the same order of magnitude as the cost of I/O operations to disk. To the extent that multiple queues are involved in an end-to-end operation, hundreds of microseconds will have been added to the overall latency of the transaction. Further, cache misses at the CPU-level, and locks requiring kernel arbitration also can be the result of traditional queueing in a messaging hug and can be very costly.
The message queue approach within a messaging hub demonstrates additional weakness—namely the potential for a deadlock condition between message producer and message consumer. Specifically, in the message queue approach, the message producer must not attempt to add data into the buffer if the buffer is full. Likewise, the message consumer must not attempt to remove data from an empty buffer. Consequently, in the message queue approach, the message producer either “sleeps” or discards data when the buffer is full. In the mean time, when the message consumer removes data from the buffer, the message consumer notifies the message producer, who in turn can add data into the buffer once again. In the same way, the message consumer can “sleep” when the message consumer finds the buffer to be empty. When the message producer subsequently adds data into the buffer, the message producer wakes the sleeping message consumer. Thus, a deadlock condition can arise where both the message consumer and message producer await awakening by the other.